Skip to content

Bump the ef-core group with 1 update - #85

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/nuget/api/ef-core-33606900a9
Open

Bump the ef-core group with 1 update#85
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/nuget/api/ef-core-33606900a9

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Aug 6, 2026

Copy link
Copy Markdown

Updated WolverineFx.EntityFrameworkCore from 6.21.0 to 6.24.7.

Release notes

Sourced from WolverineFx.EntityFrameworkCore's releases.

6.24.7

This is a fix release. Its centre of gravity is agent assignment: a leader that re-decided the same placements every cycle, and — hidden underneath that churn — a serial stop path that made every rebalance far slower than it needed to be.

Agent assignment converges much faster

#​3852 — the leader re-decided placements it had already made. The GH-3698 pending-assignment ledger armed on a ReassignAgent but could never apply one: an agent being moved is still listed in its source node's persisted ActiveAgents, so the guard that skips agents with a known original node skipped every reassignment. GH-3698 closed this hole for first-time placement and left it open for moves.

On a 512-database / 5-node / ~8,700-agent cluster that reproduced as 3,468 decisions every cycle against a frozen snapshot, indefinitely — matching the ~45,000 decisions over six minutes reported from production. It converged in spite of itself, because the batched command carries set-based value equality and the dispatcher collapses an identical re-emitted batch while its lane is busy, so it read as benign. The telemetry was not deduplicated at all: AssignmentsChanged fires before batching, so every one of those decisions wrote an AssignmentChanged node record.

The churn was concealing a second defect. StartAgents got bounded parallelism back in GH-3604 — a 50-agent chunk started one at a time was seconds of dead wall-clock that blew the reply window. The stop side is the same shape and never got it: a plain foreach, so at AgentStartBatchSize = 50 an entire chunk's stop cost ran in series before a single start could cascade. It survived only because the per-cycle churn was trickling agents onto the destination alongside the batch. Fixing the churn exposed it.

Measured against the 512-database reproduction:

6.24.6 ledger fix only 6.24.7
work reaching fresh nodes 38.0s 74.1s 14.0s
full convergence 176.3s 176.3s 31.1s

Net 5.7x faster to converge than 6.24.6, not merely quieter.

#​3850 — the cached node-number release is now bounded by a high-water mark, so a newcomer's messages cannot be released by a stale cache. Follow-up to GH-3846.

Node-number lookups happen once per node instead of once per database (#​3847, thanks @​erdtsieck) — a real saving on multi-database deployments, where the old shape scaled with the shard count.

Durability/projection affinity now reports whether it engaged

#​3785 shipped in 6.24.5: a shard database's durability agent follows that database's event-subscription agents, so the database attracts one node's connection pool instead of two.

That join is deliberately fail-silent — a miss falls back to the even spread, because a miss is never wrong, only not-better. The problem is diagnostic: a join that never fires because the two descriptor pipelines spell the same database differently looks exactly like the feature working, minus the benefit. Verifying it meant joining pg_stat_activity against the assignment table on a live cluster.

It now says so directly, once, when the numbers change:

Durability/projection database affinity (GH-3785) co-located 446 of 446 durability agents
with their database's event subscription agents across 446 databases

and escalates to a warning in the one unambiguous case — projection agents present, database-bearing durability agents present, zero matched. On a multi-database store that is a spelling divergence, not a coincidence. An application with no projections has nothing to follow and stays quiet.

Transport and listener fixes

#​3832 — a deliberately paused listener now reports the distinct ListeningStatus.Paused instead of being indistinguishable from back-pressure TooBusy. The contract now matches what the code actually does.

#​3842 — RabbitMqListener.CreateAsync no longer dereferences a null Channel when the agent is disposed mid-startup.

Testing and build

  • #​3799 — Pulsar tests share one digest-pinned broker per job rather than starting a heavy container per worker process on an unpinned :latest, which used to hang silently when Docker ran out of memory.
  • #​3800 — the CloudEvents compliance harness carries an exception type name rather than an Exception, so dead-lettering by exception type can actually be tested; ErrorCausingMessage never round-tripped through System.Text.Json.
  • #​3839 / #​3841 — the solution builds every project, including two shipping packages that previously compiled only during Pack, and the Polecat incident-service sample (whose tests had not compiled since April, with nothing noticing).

... (truncated)

6.24.6

A bug-fix release. The headline is a message ordering regression affecting every transport built on BatchedSender — if you rely on FIFO ordering anywhere, this release matters to you.

Highlights

Message ordering restored in BatchedSender (#​3825). BatchedSender ran its serializing stage at Environment.ProcessorCount, so envelopes reached the batching block in serialization-completion order rather than enqueue order.

This was a silent regression from the switch off TPL Dataflow. ActionBlock defaults MaxDegreeOfParallelism to 1 — ordered by default — and the Channels rewrite raised it without the ordering guarantee being restated anywhere. The block was ordered for years, then quietly wasn't. The practical effect: FIFO ordering was not honored under Azure Service Bus sessions, SQS FIFO message groups, or global partitioning, on every transport that uses BatchedSender. Nothing was lost; messages arrived out of order. Fixed by returning the stage to a degree of parallelism of 1 — everything downstream was already serial.

A second, independent defect fell out of the same investigation: TrackedSession.AllRecordsInOrder() sorted by SessionTime, which is ElapsedMilliseconds — whole milliseconds. An entire receive batch ties, and the stable sort then fell back to enumerating a Guid-keyed cache with no relation to real order. Every ordering assertion in the test suite was at the mercy of this. Records now carry a monotonic sequence number.

Back-pressure now works on the right number, and says what it is (#​3831, jasperfx#​632). A latched listener logged exactly one too busy line and then nothing — forever. An operator watching a queue grow for 40 minutes could not distinguish "still draining" from "wedged". Underneath that, the count a PartitionProcessingByGroupId endpoint latched and resumed against was wrong: the downstream block holding the backlog was invisible to it, so Count reported zero for work that was really there.

  • BackPressureAgent logs a periodic warning while a listener stays latched, carrying the queue count and the restart threshold the resume decision is made from.
  • The timer-driven check is exception-safe. A throw during an attempted resume was an unobserved ValueTask fault, and the listener silently never resumed.
  • BufferedReceiver/DurableReceiver wire the receiving block's OnError to ILogger. A terminally-faulted block freezes the queue count and permanently latches the listener; that now logs at Critical instead of vanishing to stderr.

A tenanted Azure Service Bus endpoint could not send at all (#​3826) — tenanted or untenanted. TenantedSender deliberately does not implement ISenderRequiresCallback, but callback registration did not recurse, so a BatchedSender underneath it kept a null callback and threw InvalidOperationException: This sender has not been registered. on every batch. The tenanted path now uses inline senders, matching how Redis, MQTT, and Pub/Sub already worked around this.

Oracle queue identity round-trip (#​3820). System.Uri lowercases the authority component while Oracle uppercases its queue identifiers, so ToOracleQueue() resolved a second endpoint over the same physical tables. Also fixes a dead final-attempt error handler: a when clause that included the loop counter made the descriptive exception at the bottom of the retry loop unreachable.

Behavior change worth reading

TrackedSession now completes only when all conditions are satisfied, not the first (#​3824). This is a public testing API. A tracked session configured with several expectations previously returned as soon as any one of them was met, which means some existing tests were passing vacuously. After upgrading, such a test waits for every condition — and may now fail where it previously passed. That failure is generally revealing a real gap rather than introducing one.

Other changes

  • JasperFx upgraded to 2.39.5. Beyond the block Count fix above, this carries jasperfx#​600/#​601 — the application-assembly stack walk could adopt a test-runner assembly and then scan an assembly holding none of your types — and jasperfx#​599, where DatabaseId's escaping now survives a System.Uri round trip.
  • EventSubscriptionAgentFamily.DatabaseKeyOf and TenantNeutralKeyOf are now public (#​3819).

Testing and CI

No runtime behavior changes here, but this is why the fixes above became findable. The Category=Flaky exclusion list went from 12 tagged classes to zero (#​3763) — and several of those tags turned out to have been added in the very commit that introduced the feature they test, hiding working code rather than broken code. Every CI readiness gate now fails loudly instead of warning and continuing; the Kafka gate in particular was a no-op that passed in 0.0s against a broker that would not serve metadata for another 3 seconds (#​3814). The retry ledger records why a test flaked rather than only which one (#​3787), and CIAzureServiceBus was sharded three ways on measured per-class durations (#​3790).

What's Changed

6.24.5

Note: 6.24.4 shipped on NuGet without a GitHub release, so these notes cover everything since V6.24.3.

Highlights

Multi-database projection & subscription assignment got a major reliability pass. For sharded event stores, Wolverine assigns the agents for projections and subscriptions in groups by database — so connection pools scale with the number of databases rather than nodes × databases:

  • A blue/green rollout carrying a projection version bump no longer assigns the new version's agents to nodes that cannot build them — previously the new version could never start anywhere for the whole rollout (#​3792, thanks @​erdtsieck). A split database now costs exactly one owner per version.
  • Database affinity is now a property of the database across agent families (#​3785): a shard database's durability agent follows that database's projection agents onto the same node, so the database attracts one node's connection pool instead of two. Measured on a 512-database production cluster, 73% of databases were split across two nodes, wasting ~425 connection slots. Expect a one-time wave of durability-agent reassignments on first deploy as an existing cluster converges.
  • The settled assignment state is now pinned as a fixed point — re-evaluating a converged cluster moves nothing — and a new deterministic simulation drives the real leader evaluation through the exact deploy shape of GH-3753: slow agent starts and a blue/green capability split at once.

Durable outbox to SNS/SQS FIFO destinations is fixed (#​3793): EnvelopeSerializer never round-tripped Envelope.DeduplicationId, so any envelope recovered from durable storage after an outage was re-sent without MessageDeduplicationId and rejected deterministically by a FIFO destination without content-based deduplication — retrying forever or dead-lettering. Also fixed alongside it: the circuit-resume ping could never reach a FIFO destination (a latched sender could never unlatch), and SNS sent MessageDeduplicationId to standard topics, which AWS rejects. The same fix is merged to the 5.x maintenance branch and will ship in the next 5.40.x release for .NET 8 users.

Balanced-mode host shutdown no longer hangs (#​3781): stopping a node while agent commands were queued could pay a full agent-batch reply window per queued command — measured at 17+ minutes. Now ~2 minutes on the same reproduction.

Azure Service Bus conventional routing sanitizes entity names (#​3786): a handler for an array message type (e.g. Handle(Foo[])) produced an illegal ASB entity name that broke broker startup for the whole assembly, and the real reason was lost. Names are sanitized and failures now carry the offending name.

What's Changed

Full Changelog: JasperFx/wolverine@V6.24.3...V6.24.5

6.24.3

What's Changed

New Contributors

Full Changelog: JasperFx/wolverine@V6.24.2...V6.24.3

6.24.2

What's Changed

Full Changelog: JasperFx/wolverine@V6.24.1...V6.24.2

6.24.1

Patch release. Four reported issues, all with reproductions from production clusters.

Fixes

#​3701 — wolverine_node_records grows without bound (#​3734)

A reporting cluster reached 36,135,221 rows / 16 GB in five days on a diagnostic table nothing on the hot path reads. Three distinct defects:

  • INodeAgentPersistence.DeleteOldNodeRecordsAsync was implemented for every relational store and never invoked outside tests.
  • The pruning that did run bounds the table by age only (NodeEventRecordExpirationTime, 5 days), which is no ceiling at all at high write rates — every one of those 36M rows was inside the window.
  • That age sweep's hourly throttle was dead. Its backing field was never assigned (the CS0649 suppression on it said so), so a full-table delete went out on every recovery cycle — every 5 seconds by default.

New Durability.NodeRecordRetention (default 10,000 rows) and Durability.NodeRecordPruningPeriod (default hourly). MultiTenantedMessageStore now delegates the trim to the main store instead of inheriting a no-op default, and Sqlite, MySQL and Oracle gained implementations they had also been missing.

#​3697 — no supported force-catch-up under Wolverine-managed event subscription distribution (#​3735)

Wolverine already implemented the coordinator-driven catch-up path, but only exposed it as a TrackActivity() stage. Adds the standalone entry point on IHost and IServiceProvider, plus <T> ancillary-store variants:

await host.PauseThenCatchUpOnMartenDaemonActivityAsync();
await host.PauseThenCatchUpOnMartenDaemonActivityAsync(CatchUpMode.AndDoNothing);
await host.PauseThenCatchUpOnMartenDaemonActivityAsync<IMyStore>();

It never calls IProjectionDaemon.CatchUpAsync — doing so under a live coordinator is what produces the ProgressionProgressOutOfOrderException and pk_mt_event_progression duplicate-key errors suites have been retrying around. Resuming the agents that already own the shards means there is only ever one writer.

#​3733 — a comma in an agent Uri voided a whole batch confirmation (#​3736)

AgentsStarted, StartAgents, AgentsStopped and StopAgents joined their Uri[] on a comma, which RFC 3986 permits unescaped in a path segment. Agent URIs embed tenant ids and projection names, so one comma shattered an agent into fragments — and because the read side built the array in a single projection, the resulting throw took out the confirmation for the entire batch. Newline is the delimiter now, and entries are parsed individually so a bad one names itself.

The comma remains the default on the wire for payloads that do not contain one, so rolling upgrades keep working in both directions.

#​3706 — RabbitMQ acks were cumulative (#​3737)

Every ack went out as BasicAckAsync(tag, multiple: true), acknowledging every lower delivery tag on the channel. That is only correct when completions happen in delivery order, and they do not with ConsumerDispatchConcurrency > 1 — acking one message silently acknowledged deliveries whose handlers were still running, and a crash at that moment lost them.

Acks are now per message. Two dead-letter paths that relied on the cumulative sweep settle themselves, most importantly the un-mappable-message branch in WorkerQueueMessageConsumer, which dead-lettered and returned without touching the delivery at all. This unblocks the planned native-ack parallel endpoint mode.

Also included

  • #​3730 — compliance coverage for a pause and node loss landing on in-flight assignments (GH-3698)
  • #​3732 — seed the departed node's inbox rows as already owned (GH-3729)

6.24.0

Two data-loss fixes — but for unusual usages

This release closes two bugs that silently destroyed data rather than failing loudly. Both are worth reading before you skip the rest of these notes.

Durable inbox rows were orphaned when a circuit breaker tripped (#​3680). DurableReceiver checked its latched flag before calling MarkReceived. The latched path still persists each envelope to the inbox as a safety net — but on an envelope that never went through MarkReceived, Status is the enum default (Outgoing) and Destination is null. Both are filter columns for inbox recovery, so the rows were written in a state no recovery sweep on any node could ever see. The null Listener also skipped the nack back to the broker, and the broker's redelivery after restart hit DuplicateIncomingEnvelopeException — which acks and drops. Net result: genuine message loss under a durable inbox any time a circuit breaker trip latched the receiver mid-flight. Measured on the circuit-breaker suite, 9 of 1,200 messages were lost per run.

Dropping one tenant from a shared partition bucket destroyed its co-tenants' data (#​3686). Found alongside #​3683. Tenant bucketing — registering several small tenants against one partition suffix so they share a physical partition — is documented and exposed through PartitionPerTenant(p => p.AllowPartitionSharing = true), and it did not work on either engine. It had no test coverage, because the doc sample demonstrating it is compile-only and never executed.

Global partitioning

Part of the GlobalPartitioning epic (#​3482).

  • Global partitioning topologies for PostgreSQL and SQL Server queues (#​3468, #​3469)
  • End-to-end sharded-processing suites for Azure Service Bus, GCP Pub/Sub, NATS, Redis Streams and Pulsar (#​3467). The scenario is lifted into Wolverine.ComplianceTests.Partitioning.ShardedProcessing, so a new transport costs one small test class
  • Native-mode design comparison and per-transport native alternatives documented (#​3481)

The new suites immediately found two real bugs:

  • NATS global partitioning had never worked at all. The topology forces EndpointMode.Durable on every slot, and a NatsEndpoint only supports Durable when JetStream-backed — so every UseShardedNatsSubjects() call threw at configuration time. The topology now enables JetStream on its own endpoints and declares a work-queue stream per shard, without which the listener died at startup on stream not found
  • Pulsar named its companion local queues off the full topic path, producing queues like global-persistent://public/default/orders1. They now use the topic's short name, matching every other transport

Multi-tenancy and persistence

  • EF Core tenant partition back-fill (#​3496). Routine migration deltas deliberately leave Weasel-managed partitions alone, so a table joining an existing managed set — a newly deployed service, or a newly mapped ITenanted entity — had no partition for any tenant registered before that table existed. IConjoinedTenantPartitions<T>.MigrateTenantPartitionsAsync() reconciles every partitioned table against the full registered tenant set, with per-table TenantPartitionResult reporting
  • Conjoined tenant partition bucketing actually works now, on both PostgreSQL and SQL Server (#​3683, and see #​3686 above)
  • Exclusive listener inbox recovery is now covered for RavenDb (#​3595) and CosmosDb (#​3596)

Transports

  • RabbitMQ: deliveries are settled against the channel they arrived on (#​3687). Acking a delivery on a torn-down channel threw a NullReferenceException
  • NATS: auto-provisioned JetStream durable consumers are filtered to their own subject (#​3676). FilterSubject was only assigned when ConsumerName was empty, so every durable consumer on a stream received every message. The fix needs a FilterSubjects multi-filter — a single filter cannot cover both {subject} and {subject}.scheduled, and a work-queue stream discards an uncovered control message
  • MQTT: the v5 authentication method name is configurable (#​3588). It was hardcoded to "OAUTH2-JWT". Azure Event Grid's custom JWT authentication requires CUSTOM-JWT, so those brokers could not be reached through Wolverine's authentication support at all. You could already set the method by hand through MqttClientOptionsBuilder.WithAuthentication(), but that gave up Wolverine's token refresh loop — the whole reason to use MqttJwtAuthenticationOptions. You no longer have to choose
  • The HTTP transport can send to a destination nobody pre-registered (#​3681, reported as ProductSupport#​34). WolverineHttpTransportClient used the endpoint's OutboundUri purely as an IHttpClientFactory client name, then posted to that client's BaseAddress — so operator commands sent back over the HTTP transport failed with An invalid request URI was provided

Performance

  • RabbitMQ consumer dispatch concurrency is now per-endpoint (#​3492). The client default of 1 was the bottleneck. Simulated handler, 2,000 msg/s offered load, 30s measured window:

    ConsumerDispatchConcurrency Throughput Transit p50
    1 (client default) 163.7/s — (nothing from the measured window was consumed before the run ended)
    5 828/s 22,871.9 ms
    20 1,999.1/s 1.486 ms (p95 2.54, p99 3.22)

    The 5.1x and 12.2x multiples understate it — at 1 and 5 the listener never catches up at all.

  • Amazon SQS batches message deletions and chunks outgoing batches on the 256KB request size limit (#​3493)

  • Azure Service Bus session listeners are no longer quadratic — the n² session loops are now n. MaxConcurrentCalls is surfaced, and a batched defer settles the original message (#​3494)

HTTP and gRPC

... (truncated)

6.23.1

Agent distribution

TL;DR: if you pause a projection from CritterWatch on 6.23.0, restarting it appears to do nothing for a full minute. This fixes that.

  • A paused projection or subscription agent now resumes immediately when you restart it (#​3663). On 6.23.0 the restart was accepted, the pause restriction was cleared, and then nothing happened until the pending-assignment ledger's TTL expired — 2 × CheckAssignmentPeriod, so 60 seconds with the defaults. Long enough that an operator reasonably concludes the agent is never coming back.

    The ledger introduced in 6.23.0 (#​3622) only counted an assignment as confirmed if a later evaluation saw the agent running and still assigned to the same node. A pause makes those two conditions mutually exclusive: the first evaluation that can observe the delivered assignment is the same one that detaches the agent. The entry was never confirmed, nothing on the stop path cleared it, and the restart's AssignAgent was suppressed as a duplicate still in flight. Delivery alone now confirms the entry, which is the only question the ledger was ever asking.

  • Pausing an agent no longer briefly starts it first (#​3666). ApplyRestrictionsAsync kickstarted a health check before persisting the operator's restriction change, so that evaluation ran against the old restrictions and could act against the very intent being applied — for a pause, re-assigning and starting the agent one beat before the merged evaluation stopped it again. Besides the wasted daemon start/stop cycle, this is what armed the stale ledger entry behind #​3663.

PostgreSQL

  • Advisory-lock sessions stay invisible to Marten's async-daemon gap detection (#​3664). Marten 9.16.1+ will not skip a stale event-sequence gap while any session whose open transaction predates that gap is still alive (marten#​4953). A session parked in an open transaction for the life of the process therefore reads as a permanent "possible reserver" and can hold the high-water mark — and every async projection — behind a gap that is genuinely dead.

    Wolverine's long-held locks were already shaped correctly: leader election and node coordination hold session-scoped advisory locks on a dedicated connection with no transaction, so they show up as state='idle' with a NULL xact_start. Those sessions are now also tagged application_name = 'wolverine-advisory-lock:<database>', which turns a pg_stat_activity investigation from guesswork into something you can read at a glance. The constraints are pinned in tests and in the Postgres durability docs, including the trap worth knowing in your own code: never add a keepalive query inside a long-lived open transaction — it bumps state_change, makes the session look active, and re-promotes it to candidate reserver.

    Note for combined Marten + Wolverine deployments: older guidance suggested Postgres's idle_in_transaction_session_timeout as a dead-gap backstop. Prefer upgrading Marten and using SkipStaleGapsDespiteLiveTransactionsAfter instead.

6.23.0

Projection & agent distribution

TL;DR: this prevents Wolverine from going into a panic doing agent assignments and churning crazily hard during Kubernetes rollouts or cluster starts and that's a very good thing

The bulk of this release. A wave of fixes (WO-1..8) to the agent assignment plane that together remove the re-assignment churn and livelock that could leave projection agents flapping or wedged.

  • Node heartbeats no longer block behind command execution (#​3620)
  • Node resurrection restores the node's real identity rather than a skeleton record (#​3621)
  • A pending-assignment ledger suppresses duplicate AssignAgent floods (#​3622)
  • Agent batch starts are chunked and bounded-parallel, so they stay safe at scale (#​3623)
  • Ejection hysteresis plus leader protection (#​3624)
  • The assignment row is re-upserted for agents that are already running (#​3619)
  • Local agents drain with bounded parallelism on shutdown (#​3636)
  • Paused shards now say why. IEventSubscriptionAgent.Failure surfaces a ShardFailure — category, the failing event's sequence and type, and the root exception type — through health checks and a new IWolverineObserver.AgentPaused hook plus a NodeRecordType.AgentPaused record. Failures bound to a specific event (ApplyEvent, EventSerialization, UnknownEventType) or to two processes racing one shard (ProgressionOutOfOrder) are no longer auto-restarted, since they would die on the identical event every time (#​3637, #​3638)
  • Agent starts retry locally, bounded by Durability.AgentStartRetryAttempts / AgentStartRetryDelay, instead of idling a full CheckAssignmentPeriod after a startup race (#​3519)
  • Store-scoped FindAgentUriAsync overload (#​3647) and a store-aware TryRebuildRegisteredProjectionAsync overload (#​3618)

Bumps JasperFx.Events to 2.36.1, Marten to 9.20.0 and Polecat to 5.7.0.

HTTP

  • Endpoints that advertise a request body their HTTP method cannot carry now fail fast at startup instead of silently 404ing out of the route matcher (#​3648)
  • A missing Content-Type on an [AcceptsContentType] route returns 415 rather than 404 (#​3649)
  • Query-only [AsParameters] endpoints no longer advertise a form body, which had been dropping them from route matching entirely (#​3630)
  • Explicitly-routed chains — PublishMessage<T> and SendMessage<T> — now describe the message they read from the body. They had been advertising no request body at all in OpenAPI (#​3646)
  • Enum values in query strings and form posts parse case-insensitively (#​3629)
  • Compiled queries returned as a Wolverine.Http resource no longer execute twice (#​3625)

Transports

  • Conventional routing respects named brokers (#​3633)
  • Google Pub/Sub: named-broker support for sharded and partitioned topics (#​3632), and ListenToPubsubSubscriptionOnNamedBroker (#​3631)
  • Kafka: topic-already-exists error codes are handled rather than thrown (#​3640)
  • Redis: scheduled retries survive an unreadable timestamp (#​3613), and scheduled entries that repeatedly fail to deserialize are dead-lettered instead of looping (#​3644)
  • EnvelopeMapper reads both timestamp header formats (#​3645)
  • NServiceBus interop: the EnclosedMessageTypes header is split before the message type is resolved, so interop works across Azure Service Bus, SNS, SQS and the database transports (#​3628)

Persistence

  • Oracle runs the durability agent through the shared batching mechanics (#​3614). Note that ODP.NET exposes no DbBatch, so the work splits per statement.

Other

  • Resource discovery no longer eager-connects broker transports (#​3617)

Contributors

Thank you to everyone who contributed to this release:

... (truncated)

6.22.0

Wolverine 6.22.0 rolls up the claim-check backend wave, distributed-agent and durability hardening, HTTP/OpenAPI binding fixes, and the Marten 9.18 / JasperFx 2.34 critter-stack alignment.

Dependency alignment

  • JasperFx family → 2.34.0
  • Marten → 9.18.0 (with Marten.AspNetCore / Marten.Newtonsoft), Polecat [5.5.0,6.0.0)
  • Weasel family → 9.18.1

Claim-check offloading

  • New NATS JetStream Object Store claim-check backend (#​3506)
  • New PostgreSQL database-LOB claim-check backend (#​3507)
  • New Google Cloud Storage claim-check backend (#​3505)
  • Size-threshold auto-offload — large payloads offload to the claim-check store automatically (#​3504)
  • Per-message / per-endpoint store selection (#​3508)
  • Honor a DI-registered IClaimCheckStore (#​3564)
  • New claim-check backends are now packed for NuGet (#​3565)

Distributed agents & durability

  • Recover exclusive listener inboxes on the listening node (#​3590)
  • Reverse the reset-clears-queue-tables behavior; add IHost.ClearAllWolverineStorageAsync() (#​3592)
  • Subscription health check uses the tenant-scoped high water mark for per-tenant subscription agents (#​3582)
  • Isolate agent start failures so one wedged agent no longer skips its siblings (#​3519)
  • Restart a projection agent whose shard wedged out from under it (#​3519)
  • EventSubscriptionAgent restores continuous execution after Rebuild/Rewind (#​3520)
  • Stamp the assigned node onto owned event-store daemons (running_on_node, marten#​5001) (#​3578)
  • Solo-mode health-check loop no longer leaks an unbounded OpenTelemetry trace (#​3518)
  • Warn loudly when a host's application assembly is pinned by an earlier host (#​3521)

HTTP & OpenAPI

  • Describe chain-bound OpenAPI params from produced variables; narrow re-reflection to postprocessors (#​3601)
  • Bind [FromQuery] on arrays/collections instead of misrouting to complex-flattening (#​3602)
  • Bind scalar [FromQuery] decimal correctly + shape-test OpenAPI parameter description across type families (#​3586)
  • Don't describe a route-bound [FromQuery]/[FromHeader] parameter twice in OpenAPI (#​3586)
  • Marten 9.18 streaming types — StreamPaged, StreamPagedByCursor, ETag support (#​3593)
  • Honour opt-in discovery filters for HTTP endpoint discovery (#​3525)
  • Never infer a DbContext parameter as the HTTP request body (#​3538)

Transports

  • Add a parallel WolverineFx.Mqtt5 package (MQTTnet 5) (#​3517)
  • Pulsar: don't claim native scheduling without a retry-letter topic (#​3491)
  • Azure Service Bus: pin session listeners to specific session identifiers (#​3533)

Persistence

  • Clear transport queue tables on message-store reset — PostgreSQL (#​3529), SQLite (#​3553), MySQL (#​3551), Oracle (#​3552)
  • Oracle: durable inbox mark-as-handled binds RAW(16) Guid correctly (#​3581)
    ... (truncated)

Commits viewable in compare view.

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
  • @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
  • @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
  • @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
  • @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

@dependabot
Bump the ef-core group with 1 update
6d02438 
Bumps WolverineFx.EntityFrameworkCore from 6.21.0 to 6.24.7

---
updated-dependencies:
- dependency-name: WolverineFx.EntityFrameworkCore
  dependency-version: 6.24.7
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: ef-core
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added .NET Pull requests that update .NET code dependencies Pull requests that update a dependency file labels Aug 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file .NET Pull requests that update .NET code

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants